A Name Authority Pointer (NAPTR) is a type of resource record used in the Domain Name System (DNS).[1][2]
Contents |
Uniform Resource Names (URNs) are a subset of Uniform Resource Identifiers (URIs) used for abstract identifiers, such as a person's name or their telephone number. For URNs to be meaningful, they must be mapped to a concrete resource of some sort. Uniform Resource Locators (URLs) are often used to describe such resources, such as a computer hostname, or a local file.
As part of the standardization of URNs, NAPTR records were introduced to do just this. NAPTR records map between sets of URNs, URLs and plain domain names and suggest to clients what protocol should be used to talk to the mapped resource.[3] Each NAPTR record contains a service name, a set of flags, a regexp rule, an order value, a preference and a replacement. Multiple records can be chained together in a cascade to rewrite URIs in fairly sophisticated, but deterministic ways. These cascading rules have been standardized in RFC2915 and RFC3403.
A common use for NAPTR records is in SIP, where it is used to route phone calls over the Internet. For example, the SIP URN for the US telephone number 1-800-555-1234 would be tel:+1-800-555-1234 and its domain name 4.3.2.1.5.5.5.0.0.8.1.e164.arpa. A SIP client doing a lookup on that name might receive:
$ORIGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:customer-service@example.com!" . IN NAPTR 102 10 "U" "E2U+email" "!^.*$!mailto:information@example.com!" .
The first record has an order value of 100, which is lower than 102, so it is picked first. Its preference of 10 is unimportant as there are no other rules with order 100. The service name E2U+sip is an ENUM string indicating that the record can be used in phone number-to-SIP lookups.[4] The client then goes on to apply the regexp rule !^.*$!sip:customer-service@example.com!, which replaces its entire lookup URN tel:+1-800-555-1234 with sip:customer-service@example.com. The "U" flag indicates that the replacement string is a SIP URN, and that no further rules should be applied.
To resolve SIP URN, the client then performs a second NAPTR lookup—on example.com, yielding:
$ORIGIN example.com. IN NAPTR 100 10 "S" "SIP+D2U" "!^.*$!sip:customer-service@example.com!" _sip._udp.example.com. IN NAPTR 102 10 "S" "SIP+D2T" "!^.*$!sip:customer-service@example.com!" _sip._tcp.example.com.
As before, the client picks the first record because it has the lowest order value. The regexp rule replaces the lookup URN, this time with the domain name _sip._udp.example.com. The "S" flag indicates that resulting domain name points to a SRV record. The client thus finishes with _sip._udp.example.com, for which it can then fetch a SRV record to initiate a VOIP call.
Vendor | Product | NAPTR support? |
---|---|---|
ISC | BIND | Yes |
Cisco Systems | CNR | Yes |
Daniel Bernstein | djbdns | No (requires patch) |
Microsoft | Windows Server 2003 DNS Server | No |
Microsoft | Windows Server 2008 R2 DNS Server | Yes |
Bert Hubert | PowerDNS | Yes |
NLnet Labs | NSD | Yes |
Sam Trenholme | MaraDNS | Yes (as of version 1.4[5]) |
Unixservice, LLC. | unxsBind | Yes |
Simon Kelley | Dnsmasq | Yes |
EDNS is required for NAPTR implementations, as extended-length DNS packets are needed to encapsulate queries returning multiple NAPTR records.